perm filename REM.WRU[W76,JMC] blob
sn#203308 filedate 1976-02-20 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂19-FEB-76 0600 REM via AMET IMPROVEMENTS TO CRU2
C00005 ENDMK
C⊗;
∂19-FEB-76 0600 REM via AMET IMPROVEMENTS TO CRU2
There is a check to be sure the number of nodes in the history tree plus 1
equals the number of trunks in the Huffman-trees file, whenever the latter
is loaded. When a file doesn't exist, or a output file already exists,
or a password in a file is unknown, it now types reasonable messages and
returns to command level. Program tells c.r. (appx) when crunching, and
exactly when uncrunching. (In the former case the possibility of line-numbers,
directory-pages, nulls etc. cause ambiguity in definition of c.r.)
If a history tree is loaded and one is already loaded, core used for both
the old history tree and Huffman trees are recycled. If a Huffman tree file
is loaded, just the old Huffman trees are recycled. Thus except for the
command scanner (it asks you one thing at a time, rather than accepting
a full command COM OFILE←IFILE/SWITCHES<CR>) it seems to be in usable shape.
Of course, some system programs, such as COLIST, operate in one-at-a-time
mode, so I guess CRU2 is acceptable now, modulo any bugs I haven't found yet.
So, CRU2[1,REM] awaits your trial...
∂20-FEB-76 0458 REM via AMET New features in CRU2
CRU2 now includes a hash number for the history-tree and a hash
number for the Huffman-trees in each crunched file. Thus if you don't
include the trees in the crunched file, the program can at least check
at the onset of uncrunching to see if you are going to win.
There was a bug in the Yes/No routine, it took all answers to
be Yes regardlss of what you typed.
Unless more bugs exist, it is ready for you to play with.